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DETAILED ACTION 

1 . This Office Action is taken in response to Applicants' Request for Continued 
Examination (RCE) filed on September 21, 2006 regarding application 10,722,761 filed 
on November 26, 2003. 

2. Claims 1, 18, 21, 40-41 and 43-44 have been amended. 
Claims 1-44 are pendingjor consideration. 

3. Response to Remarks and Amendments 

Applicants' amendments and remarks have been fully and carefully considered. 
In response to the amendments, a new ground of claim analysis has been made. 
Refer to the corresponding sections of the claim analysis for details. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. Claims 1, 3-27 and 32-44 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Daynes (U.S.' 6,343,339), and in view of Ofer (US 6,691,194). 

As to claim 1 , the references discloses a memory for storing a computer- 
implemented shared locking data store ^DaynesJ : A lock is comprised of a data 



structure that records the identity of the transactions that are given the right to execute 
operations on the resource the lock protects. Each time a lock is acquired, memory is 
used for the lock data structure (column 3, lines 31-39); lOferi : figures 3-4; a main lock 
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data structure is implemented in a shared memory accessible ... (column 3, lines 44- 
52)] for handling multiple executable entities' access to at least one resource 

flDavnesl : Each time a computer system performs an activity, the activity is referred to 
as a transaction. ... When executing transactions, a computer system may execute a 
group of transactions at one time (column 1 , lines 40-62); One type of lock is a shared 
lock. A shared lock permits multiple transactions to read (view) an item simultaneously 
without any modification or addition to the item (no writing is permitted) (column 2, lines 



18-21); [Qferl : figure 2; column 3, lines 44-52], said shared locking data store being 



stored in a computer memory flDavnesl : A lock is comprised of a data structure that 
records the identity of the transactions that are given the right to execute operations on 
the resource the lock protects. Each time a lock is acquired, memory is used for the 
lock data structure (column 3, lines 31-39); lOferi : figures 3-4; a main lock data structure 
is implemented in a shared memory accessible ... (column 3, lines 44-52)], said 
shared locking data store comprising: 

write requested data that is indicative of when a write request for the resource 



has been made flDavnesl : figures 3-4, write lock (W); figure 7, step 702, "any pending 
lock requests or conflicts?" step 704C, "place lock request in queue;" A lock state is 
comprised of a set of transactions that own a lock in a specific mode. Among other 
modes, a locking mode may comprise a read mode or a write mode (column 4, lines 2- 
5); Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
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(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); 

lOfeit column 9, lines 43-67, column 10, lines 1-67 and column 11, lines 1-31; although 
Qfer does not explicitly specify a request to be a read or a write, it is understood that 
any request must be either a read or a write]; 

writer active data that is indicative of whether a writer process is actively 



undergoing a write operation with respect to the resource HDavnesI : single write 
owner (SRO): the lock state type that represents ownership by a single owner in write 
mode. There is one lock state of this type per active transaction (column 16, lines 10- 
13); figures 3-4; figure 7; conflict detection, column 18, lines 7-14; 
lOferi : column 9, lines 43-67, column 10, lines 1-67 and column 11, lines 1-31; although 
Qfer does not explicitly specify a request to be a read or a write, it is understood that 
any request must be either a read or a write]; 

wait event posted data, wherein the wait event posted data is indicative of 
whether a read request to the resource has completed, wherein the wait event 
posted data is used to indicate when a write request can access the resource 

[|DaynesJ : Additionally, locks must be administered to provide a queue for transactions 



that are waiting to acquire a lock, and to rollback any executed actions if a deadlock 
results (i.e., when each of two transactions are waiting for a lock release from the other 
before continuing) (column 2, lines 29-41); In one embodiment, the queue is processed 
in first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
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conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 11, lines 26-33); 

lOferi : the queue lock is implemented by a main lock data structure (column 6, lines 38- 

41)]; 

reader data that is indicative of whether a reader process is active and 
attempting to read from the resource f|Dgynes| : figures 3-4, read lock (R); figure 7, 



step 702, "any pending lock requests or conflicts?" step 704C, "place lock request in 
queue;" A lock state is comprised of a set of transactions that own a lock in a specific 
mode. Among other modes, a locking mode may comprise a read mode or a write 
mode (column 4, lines 2-5); Additionally, locks must be administered to provide a 
queue for transactions that are waiting to acquire a lock, and to rollback any executed 
actions if a deadlock results (i.e., when each of two transactions are waiting for a lock 
release from the other before continuing) (column 2, lines 29-41); 



Oferi : column 9, lines 43-67, column 10, lines 1-67 and column 11, lines 1-31; although 
Ofer does not explicitly specify a request to be a read or a write, it is understood that 
any request must be either a read or a write]; 

wherein the shared locking data store allows writer and reader locking state 
information to be determined so that access to the resource can be handled 



flDaynesJ : figures 4-7; figure 11; Method and apparatus for locking by sharing lock 
states. Each resource is associated with a lock state that represents its lock. Lock 
states are made of one set of transactions per locking mode (abstract); 
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Oferi : figures 5-9; column 9, lines 43-67, column 10, lines 1-67 and column 11, lines 1- 
31]; 

wherein encapsulation of both lock status data and the reader data in the shared 
locking data store allows a hardware atomic operation to operate upon both the 
lock status data and the reader data as a single unit for determining how access 



to the resource is to be handled flDavnesI : In one embodiment, lock state sharing 



enables the usage of non-blocking synchronizations to change the lock state of a 
resource. A non-blocking synchronization requires an implementation using an atomic 
compare and swap operation (such as the cas instruction of the Sparc V9 processor, or 
the cmpxchg instruction of the Intel486 and Pentium family of processors) (column 17, 
lines 18-56); 

lOferi : the main lock data structure provides, in a single atomic structure, the resources 
needed to lock a shared resource (column 3, lines 47-49); column 4, lines 51-56; 
column 5, lines 8-14]. 

Regarding claim 1, Daynes does not teach the limitation of "encapsulation of 
both lock status data and the reader data in the shared locking data store allows 
a hardware atomic operation to operate upon both the lock status data and the 
reader data as a single unit." 

However, Daynes does teach using an atomic compare and swap operation for 
determining how access to the resource should be handled [column 17, lines 18-56]. 

Further, Ofer discloses in the invention "Selective Association of Lock Override 
Procedures with Queued Multimode Lock" a lock data structure [figures 3-4; column 3, 
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lines 44-52] which encapsulate both lock status data [LOCK_PW, figure 3, 35; 
column 10, lines 28-34] and the reader data [NEXT_FREE, figure 3, 39; column 10, 
lines 40-44] in the shared locking data store [figures 3-4; column 3, lines 44-52] 
allows a hardware atomic operation to operate upon both the lock status data 
and the reader data as a single unit [the main lock data structure provides, in a 
single atomic structure, the resources needed to lock a shared resource (column 3, 
lines 47-49); column 4, lines 51-56; column 5, lines 8-14] for determining how access 
to the resource is to be handled [figures 5-9]. 

Encapsulation of both lock status data and reader data as a single unit for atomic 
operations further reduces the pitfalls of deadlock or starvation situations [Ofer, column 
2, lines 15-16]. 

r 

Therefore, it would have been obvious for one of ordinary skills in the art at the 
time of Applicant's invention to recognize that benefits of encapsulation of both lock 
status data and reader data as a single unit for atomic operations, as demonstrated by 
Ofer, and to incorporate it into the existing scheme disclosed by Daynes to further 
reduces the pitfalls of deadlock or starvation situations. 

As to claim 3, Daynes teaches that the multiple executable entities include 
threads which are to access the resource [Each time a computer system performs 
an activity, the activity is referred to as a transaction . ... When executing transactions, 
a computer system may execute a group of transactions at one time (column 1 , lines 
40-62); One type of lock is a shared lock. A shared lock permits multiple transactions 
to read (view) an item simultaneously without any modification or addition to the item 
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(no writing is permitted) (column 2, lines 18-21)], wherein the threads comprise a 
writer thread and a reader thread [figures 3-4; read (R) and write (W)], wherein the 
locking state information is used to determine how the writer thread and the 
reader thread access the resource [figures 4-7; figure 1 1 ; Method and apparatus for 
locking by sharing lock states. Each resource is associated with a lock state that 
represents its lock. Lock states are made of one set of transactions per locking mode 
(abstract)]. 

As to claim 4, Daynes teaches that the resource requires protection on a per 
thread basis [figures 3-4, the lock state of read (R) and write (W) is based on a per 
transaction (T) basis]. 

As to claim 5, Daynes teaches that the locking state information indicates 
where in the overall locking process an operating system is with respect to the 
resource [figures 4-7; figure 11]. 

As to claim 6, Daynes teaches that the request of the reader thread is allowed 
to succeed unless there is a write request active or pending as indicated by the 
write requested data and the writer active data [figure 7]. 

As to claim 7, Daynes teaches that rules mechanism that indicates how 
resource access requests are to be handled based upon the data stored in the 
shared locking data store [figures 4-7; figure 11; Method and apparatus for locking by 
sharing lock states. Each resource is associated with a lock state that represents its 
lock. Lock states are made of one set of transactions per locking mode (abstract); 
Additionally, locks must be administered to provide a queue for transactions that are 
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waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41)]. 

As to claim 8, Daynes teaches that the rules mechanism includes allowing 
any number of read requests to succeed unless there is a writer active or 
pending as indicated by the shared locking data store [multiple read owner (MRO): 
the lock state type that represents ownership by multiple owners in read mode only 
(column 16, lines 14-16); figure 7; conflict detection, column 18, lines 7-14]. 

As to claim 9, Daynes teaches that the rules mechanism includes allowing 
only one writer to be active at any given time [single write owner (SRO): the lock 
state type that represents ownership by a single owner in write mode. There is one 
lock state of this type per active transaction (column 16, lines 10-13); figures 3-4; figure 
7; conflict detection, column 18, lines 7-14]. 

As to claim 10, Daynes teaches that the rules mechanism includes that no 
preference is given when deciding which of waiting read or write requests 
should be honored first [the procedures shown in figures 3-4 and 7 do not give 
preference to either read or write requests] 

As to claim 1 1 , Daynes teaches that the rules mechanism substantially 
eliminates a reader request starvation or a writer request starvation situation 
with respect to the resource [the procedures shown in figures 3-4' and 7 do not give 
preference to either read or write requests, is fair to both read and write requests, 
hence prevent starvation of either read requests or write requests]. 
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As to claim 12, Daynes teaches the resource comprises data stored in 
computer memory [A transaction may need access to a record in a database or a 
portion of information in a database (column 1 , lines 47-49)]. 

As to claim 13, Daynes teaches that the resource comprises a computer file 
[A transaction may need access to a record in a database or a portion of information in 
a database (column 1, lines 47-49)]. 

As to claim 14, Daynes teaches that the resource comprises an input/output 
device [I/O devices, figure 1 , 1 1 9]. 

As to claim 15, Daynes teaches that the write requested data is to have a set 
status when a write request has been made [lock set, column 15, lines 7-39]. 

As to claim 16, Daynes teaches that a set status for the write requested data 
indicates whether an operating system (OS) mutex lock is to be used for 
processing access to the resource [Additionally, locks must be administered to 
provide a queue for transactions that are waiting to acquire a lock, and to rollback any 
executed actions if a deadlock results (i.e., when each of two transactions are waiting 
for a lock release from the other before continuing) (column 2, lines 29-41); In one 
embodiment, the queue is processed in first-in-first-out (FIFO) order. At step 706, the 
lock manager waits for the requested lock to become available. In one embodiment, a 
lock may become available when the conflict is cleared (e.g., when the lock is released 
by another transaction) and when transactions that were ahead of the current 
requestor in the queue have been processed (column 1 1 , lines 26-33)]. 
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As to claim 17, Daynes teaches that indication of whether a writer process is 
active by the writer active data is used to protect against readers posting an 
operating system (OS) event after the writer thread has been activated 

[Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 1 1 , lines 26-33)]. 

As to claim 18, Daynes teaches that the shared locking data store of claim 1 
further comprising wait event posted data, wherein the wait event posted data is 
indicative of whether a read request to the resource has completed, wherein the 
wait event posted data is used to indicate when a write request can access the 
resource, wherein a last active read clears status of the wait event posted data 
prior to posting an event [Additionally, locks must be administered to provide a 
queue for transactions that are waiting to acquire a lock, and to rollback any executed 
actions if a deadlock results (i.e., when each of two transactions are waiting for a lock 
release from the other before continuing) (column 2, lines 29-41); In one embodiment, 
the queue is processed in first-in-first-out (FIFO) order. At step 706, the lock manager 
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waits for the requested lock to become available. In one embodiment, a lock may 
become available when the conflict is cleared (e.g., when the lock is released by 
another transaction) and when transactions that were ahead of the current requestor in 
the queue have been processed (column 1 1 , lines 26-33)]. 

As to claim 19, Daynes teaches that the clearing ensures that one and only 
one posting to a writer of an event occurs [In one embodiment, a lock may become 
available when the conflict is cleared (e.g., when the lock is released by another 
transaction) and when transactions that were ahead of the current requestor in the 
queue have been processed (column 1 1 , lines 26-33)]. 

As to claim 20, Daynes teaches that the posting occurs if status of the writer 
active data is not set [figure 7, step 708, "value of new lock state computed" as a 
result of no pending lock requests or conflicts (step 702)]. 

As to claim 21, Daynes teaches that the processes comprise threads, wherein 
the wait event posted data indicates when events can be posted by one thread to 
notify another thread that the other thread's request can be processed [figure 1 0 
shows that the read (R) and Write (W) tables indicate which transactions may be using 
which resources]. 

As to claim 22, Daynes teaches that the wait event posted data indicates 
whether a reader thread can post a lock release event to a writer thread [figure 
10]. 
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As to claim 23, Daynes teaches that the wait event posted data is used to 
prevent multiple reader threads from posting redundant lock release events 

[figure 10; column 13, lines 61-67, column 14, lines 1-18]. 

As to claim 24, Daynes teaches that the write requested data, writer active 
data, and wait event posted data provide multi-threaded protection in place of an 
operating system (OS) mutex [One type of lock is a shared lock. A shared lock 
permits multiple transactions to read (view) an item simultaneously without any 
modification or addition to the item (no writing is permitted) (column 2, lines 18-21); 
Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 11, lines 26-33]. 

As to claim 25, Daynes teaches that the shared locking data store of claim 18, 
wherein locking state data comprises the write requested data, the writer active 
data, the reader count data, and the wait event posted data [refer to "As to claim 
1"]; wherein the locking state data is formatted as a single atomic unit [SRO (figure 11, 
1120) and MRO (figure 11, 1126); column17, lines 17-56]. 
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As to claim 26, Daynes teaches that the shared locking data store of claim 25, 
wherein the locking state data is formatted as a multi-bit single unit [SRO (figure 
11, 1120) and MRO (figure 11, 1126); In one embodiment of the invention, lock owner 
sets are represented as bitmaps. A bitmap is an array of binary digits (either a 1 or 0 in 
the binary number system; also referred to as bits). Additionally, each transaction is 
assigned a locking context that uniquely identifies the transaction (column 14, lines 19- 
30)]. 

As to claim 27, Daynes teaches that the shared locking data store of claim 26, 
wherein the formatting of the locking state data as a single unit allows an 
operating system to use atomic operations upon the locking state data [In one 

embodiment, lock state sharing enables the usage of non-blocking synchronizations to 
change the lock state of a resource. A non-blocking synchronization requires an 
implementation using an atomic compare and swap operation (such as the cas 
instruction of the Sparc V9 processor, or the cmpxchg instruction of the Intel486 and 
Pentium family of processors) (column 17, lines 18-56)]. 

As to claim 32, Daynes teaches that the locking state data is formatted as a 
multi-bit single unit [SRO (figure 11, 1120) and MRO (figure 11, 1126); In one 
embodiment of the invention, lock owner sets are represented as bitmaps. A bitmap is 
an array of binary digits (either a 1 or 0 in the binary number system; also referred to 
as bits). Additionally, each transaction is assigned a locking context that uniquely 
identifies the transaction (column 14, lines 19-30)]; 
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wherein the write requested data comprises a single bit in the unit [figure 1 1 , 
column 14, lines 19-30]; 

wherein the writer active data comprises a single bit in the unit [figure 1 1 , column 
14, lines 19-30]; 

wherein the wait event posted data comprises a single bit in the unit [figure 1 1 , 
column 14, lines 19-30]; 

wherein the reader data comprises a plurality of bits in the unit to indicate 
number of active readers with respect to the resource [figure 11, column 14, lines 
19-30]. 

As to claim 33, refer to "As to claim 32." 

As to claim 34, Daynes teaches that the reader data's count of the readers 
provides an indication as to whether readers are present and when the last 
reader exits [figure 1 1 , column 14, lines 19-30; figures 3-4 and 10]. 

As to claim 35, Daynes teaches that a read lock acquisition means accesses 
the locking state data for processing a read lock acquisition of the resource 
[figures 3-4, read lock (R); figure 7, step 702, "any pending lock requests or conflicts?" 
step 704C, "place lock request in queue;" A lock state is comprised of a set of 
transactions that own a lock in a specific mode. Among other modes, a locking mode 
may comprise a read mode or a write mode (column 4, lines 2-5)]. 



I 
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As to claim 36, Daynes teaches that a read lock release means accesses the 
locking state data for processing a read lock release of the resource [figure 10 
shows how to acquire and release a read lock]. 

As to claim 37, Daynes teaches that a write lock acquisition means accesses 
the locking state data for processing a write lock acquisition of the resource 
[figures 3-4, write lock (W); figure 7, step 702, "any pending lock requests or conflicts?" 
step 704C, "place lock request in queue;" A lock state is comprised of a set of 
transactions that own a lock in a specific mode. Among other modes, a locking mode 
may comprise a read mode or a write mode (column 4, lines 2-5)]. 

As to claim 38, Daynes teaches that a write lock release means accesses the 
locking state data for processing a write lock release of the resource [To release 
a lock for a specific resource, the transaction determines the lock state value that will 
result after removing itself from the lock state for that resource (column 4, lines 28-30)]. 

As to claim 39, Daynes teaches that the operating system returns a lock busy 
status indicator when a lock cannot be obtained within a predetermined time 
[Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
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transactions that were ahead of the current requestor in the queue have been 
processed (column 1 1 , lines 26-33]. 

As to claim 40, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 41 , refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 42, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 43, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 44, refer to "As to claim 1" presented earlier in this Office Action. 
6. Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Daynes 
(U.S. 6,343,339), and in view of Ofer (US 6,691,194). 

As to claim 2, Daynes teaches that the executable entities include processes, 
threads, stand-alone application or code that runs at the request of another 
program wherein use of the shared locking data stores allows for the avoidance 
of an operating system call or avoidance of a resource accessing trap of the 
operating system's kernel [refer to "As to claim 1"]. 

Regarding claim 2, neither Daynes nor Ofer mention that the executable 
entities include daemons, applets, servlets or ActiveX components. 

However, these entities are well known in the art and have been widely used in 
computer systems (see Microsoft Computer Dictionary, 5 th edition, Microsoft Press, 
2002, isbn 0-7356-1495-4; page 140 - daemon; page 31 - applet; page 18 - ActiveX; 
page 475 - servlet). 

Therefore, it would have been obvious for one of ordinary skills in the art at the 
time of Applicant's invention to recognize that these entities are well known in the art 
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and have been widely used in computer systems, hence lacking patentable 
significance. 

7. Claims 28-31 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Daynes (U.S. 6,343,339), in view of Ofer (US 6,691 ,194), and further in view of 
Mckenney et al. (US 6,480,918). 

As to claims 28-31, Daynes teaches the use of atomic sub operation [A non- 
blocking synchronization requires an implementation using an atomic compare and 
swap operation (such as the cas instruction of the Sparc V9 processor, or the cmpxchg 
instruction of the Intel486 and Pentium family of processors) (column 17, lines 18-56)], 
but does not mention that the atomic operations include atomic get, atomic set, and 
atomic add operation. 

However, these atomic operations are well known and commonly used in the art. 
Further, Mckenney et al. disclose in their invention "Lingering Locks with 
Fairness Control for Multi-Node Computer Systems" a scheme of lock management in 
a multiprocessor computer system [abstract] wherein atomic get [atomically acquiring 
the lock (column 24, lines 65-66)], atomic set [atomically setting the available bit 
(column 25, lines 25-26)], atomic add [atomic add (atomic_xadd_uint) (column 10, lines 
29-30)] and atomic sub [atomic compare-and-exchange (atomic_cmp_xchng_uint) 
(column 10, lines 30-31)] operations are used to facilitate the control of locks. 

Therefore, it would have been obvious for one of ordinary skills in the art at the 
time of Applicant's invention to recognize that these atomic operations are well known 
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in the art and have been widely used in computer systems, as demonstrated by 
Mckenney et al., hence lacking patentable significance. 
8. Related Prior Art of Record 

The following list of prior art is considered to be pertinent to applicant's invention, 
but not relied upon for claim analysis conducted above. 

■ Oliver, (US 6,029190), "Read Lock and Write Lock management system Based 

upon MUTEX and Semaphore Availability." 

■ Ofer, (US 6,718,448), "Queued Locking of a Shared Resource Using Multimodal 

Lock Types." 

■ McClaughry et al., (US 5,933,825), "Arbitrating Concurrent Access to File system 

Objects." 

- McKenney, (US Patent Application Publication 2004/0117531), "Adaptive 
Reader-Writer Lock." 

■ Kakivaya et al., (US 6,546,443), "Concurrency-Safe Reader-Writer Lock with 

Time Out Support." 

■ Clark, (US 6,598,068), "Method and Apparatus for Automatically Managing 

Concurrent Access to a Shared Resource in a Multi-Threaded Programming 
Environment." 

■ Bacon, (US 6,247,025), "Locking and Unlocking Mechanism for Controlling 

Concurrent Access to Objects." 

■ Watanabe et al., (US 6,016,490), "Database Management System." 
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■ Harris, (US Patent Application Publication 2003/0200398), "Method and 
Apparatus for Emulating Shared Memory in a Storage Controller." 

■ Onodera et al., (US 6,883,026), "Method and Apparatus for Managing Locks of 

Objects and Method and Apparatus for Unlocking Objects." 

■ Won et al., (US Patent Application Publication 2003/0126187), "Method and 

Apparatus for Synchronization in a Multi-Thread system of JAVA Virtual 
machine." 

■ Li, (US Patent Application Publication 2004/0059733), "Method and Apparatus 
for Locking Objects in a Multi-Threaded Environment." 

■ Li, (US Patent Application Publication 2003/0233393), "Thread Optimization for 

Lock and Unlock operations in a Multi-Threaded Environment." 

Conclusion 

9. Claims 1-44 are rejected as explained above. 

10. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sheng-Jen Tsai whose telephone number is 571-272- 
4244. The examiner can normally be reached on 8:30 - 5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Matthew Kim can be reached on 571-272-4182. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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